ベストプラクティスを知ろう (3) #サービスマネジメント
prismatix事業部 の菊地です。
みなさま、日々の運用、お疲れさまです。
前回は「ITIL 4」の第二弾として、主に「Ops」に関連する管理プラクティスのうち、サービスプロバイダがあらかじめ用意すべき、以下の管理プラクティスについてご紹介しました。
- サービスデスク
- サービスカタログ管理
- サービス構成管理
- サービス要求管理
- 変更管理
今回は「ITIL 4」の第三弾として、主に「Ops」に関連する管理プラクティスのうち、インシデントや問題、継続的改善など、発生した課題の解決に必要となる、管理プラクティスについてご紹介します。
- インシデント管理
- 問題管理
- 継続的改善
ITIL 4 管理プラクティス
まずはじめに、前々回のおさらいとして ITIL 4 で管理されるプラクティスについて種類毎にご紹介します。
| 一般的マネジメントプラクティス | サービスマネジメントプラクティス | 技術的マネジメントプラクティス |
|---|---|---|
| アーキテクチャ管理 継続的改善 情報セキュリティ管理 ナレッジ管理 測定および報告 組織変更の管理 ポートフォリオ管理 プロジェクト管理 関係管理 リスク管理 サービス財務管理 戦略管理 サプライヤ管理 |
要員およびタレント管理 可用性管理 事業分析 キャパシティおよびパフォーマンス管理 変更管理 インシデント管理 IT 資産管理 モニタリングおよびイベント管理 問題管理 リリース管理 サービスカタログ管理 サービス構成管理 サービス継続性管理 サービスデザイン サービスデスク サービスレベル管理 サービス要求管理 |
サービスの妥当性確認およびテスト 展開管理 インフラストラクチャおよびプラットフォーム管理 ソフトウェア開発および管理 |
ITIL 4 ではこれらのプラクティスを管理することで、サービス全体を適切に管理していくことを目指していますが、次に「Ops」に関連する主要な管理プラクティスについて、より具体的な内容を見ていきたいと思います。
なお今回の記事では JIPDEC ([一財]日本情報経済社会推進協会) が公開している「ITSMSユーザーズガイド」を参考にしています。詳細につきましては以下ガイドをご確認ください。
ITSMSユーザーズガイド-JIS Q 20000-1:2020 (ISO/IEC 20000-1:2018)対応- https://www.jipdec.or.jp/archives/publications/JIP-ITSMS111-30.pdf
インシデント管理
インシデントとは、サービスの計画外の中断、または合意したサービスレベルから品質が低下することを指し、インデントの発生はユーザの満足度に対して大きな影響を与える可能性があります。
インシデント管理プラクティスは、発生したインシデントに対して、できる限り速やかに、合意したサービスレベルの範囲内で、サービスを復旧させることを目的としています。
インシデント管理フロー
インシデント管理フローは以下の通りとなります。
出典： [一財]日本情報経済社会推進協会「ITSMSユーザーズガイド」
インシデント管理の活動
インシデント管理の各活動は以下の通りとなります。
インシデントの検知・検出
監視システムにより検知したり、ユーザよりサービスデスクに対して申告があることで、インシデントが検知されます。インシデントがユーザに影響を与える前に検知されることが望ましいかたちと言えます。
記録の開始
インシデントが検知された時点から記録が開始される必要があります。
インシデントが検知され、終了されるまでに至る進捗を適切に共有し、またそれをトレース出来るように、次のような情報について記録することを検討する必要があります。
- インシデントのカテゴリ、緊急度、インパクト、優先度
- 記録した日時、記録者
- 通知方法
- ユーザ情報
- 症状
- ステータス（対応中、待機中、クローズなど）
- 関連のある構成要素、問題、既知の誤り
- インシデント対応者
- インシデント対応内容
- 解決した日時
- クローズのカテゴリ、日時
分類
検知されたインシデントに対して、いくつかの観点からインシデントを分類します。
優先順位付け
インシデント管理の重要な点は、インシデントに対して優先度を付けることです。これは、そのインシデントにより引き起こされるサービスへの影響と、そのサービスが持っている緊急度により決定されます。一般的に緊急度は、インシデントが検知されてからサービスが影響を受け、ユーザに影響を与え始めるまでの時間に基づいて設定されます。
調査と診断
過去の事例（既知の誤り）やあらかじめ準備されている解決策や回避策（ワークアラウンド）などを活用し、迅速に調査と診断を実施する必要があります。
エスカレーション
サービスデスクだけでは合意されている時間内に解決できない場合は、別のチームからサポートを受ける必要が出てきます。このような組織的な連携をエスカレーションと呼びます。
解決と復旧
他のチームに復旧処置を依頼したり、ベンダーに障害対応を依頼するなどして、インシデントの解決と復旧に努めます。
終了（クローズ）
通常は１次対応者であるサービスデスクがインシデントを終了します。この場合、根本原因がわかっておらず、回避策（ワークアラウンド）で対処したとしてもインシデントは終了されます。なおインシデントを終了する前に、インシデントが解決されかつその対応終了に同意することを、インシデントの報告者に確認する必要があります。
重要なインシデントへの対応
重要なインシデントが発生した場合、サービスを提供している関係者を招集し、善後策を検討します。関係者とは、社内およびサプライヤのスタッフ、サービスマネージャやサービスオーナー、サービスデスクの代表者などです。検討した善後策と実施した活動について、インシデントの一部として記録に残します。
重大なインシデントについては、次の内容を管理することが望ましいとされています。
- 重大なインシデントを特定する基準の決定
- 文書化された手順に従い、分類ならびに管理されること
- トップマネジメントに通知され、管理する責任を個人に割り当てること
- 重大なインシデントの解決後、報告と改善の機会を特定するためのレビューを行うこと
問題管理
問題管理とは、一つ以上の実際に起きたインシデント、および潜在的なインシデントにおける、原因を管理することを指します。
問題管理プラクティスでは、インシデントによるサービス提供の中断リスクを最低限に抑えるため、インシデントを引き起こした原因の究明や、問題の恒久的な解決策を提供し、さらに再発予防までを目的としています。
問題管理フロー
問題管理フローは以下の通りとなります。
出典： [一財]日本情報経済社会推進協会「ITSMSユーザーズガイド」
問題管理は前後半に分けて大きく２つのフェーズが存在します。
原因究明
前半部分は問題の根本原因を突き止めることです。
根本原因が究明された問題、もしくはサービスへの影響を軽減もしくは除去する方法（ワークアラウンド）が特定された問題は、既知の誤りとなります。問題ならびにワークアラウンドは、問題の記録として全て記録しておくことで、今後発生したインシデントにおいて役立つことがあります。
なお問題の解決が難しい場合、ワークアラウンドの実施をもって問題の終了とすることがあります。
問題解決
後半部分は実際に問題を解決する活動です。問題を解決するために変更が必要な場合、変更自体は変更管理プラクティスによって管理され、問題管理プラクティスの対象外となります。
問題管理の活動
問題管理の各活動は以下の通りとなります。
- 問題の識別
- 問題の記録
- 問題の分類
- 優先度付け
- エスカレーション
- 問題の解決
- 問題の終了
継続的改善
継続的改善とは、サービス自体やサービスマネジメントの適切性、妥当性および有効性について、継続的に改善することを指します。
継続的改善プラクティスは、改善の機会に対して評価基準を設けて、優先順位付けを行い、承認された改善には計画を策定し、改善を管理することを目的としています。
なおサービス改善の実施に先立って、サービス品質およびサービスレベルのベースラインを記録し、改善を実施する前と後とを比較し評価することは、改善の効果を測るうえでとても重要です。
また改善の効果は、品質面、費用面、資源などの活用について予測され、判定可能な目標として設定されることが求められます。
継続的改善の活動
継続的改善の各活動は以下の通りとなります。
- 改善の目標設定
- 改善の優先度付け
- 改善の計画と実施
- 改善の結果測定
- 改善の結果報告
サービスマネジメントシステムを構築しよう
ここまで「ITIL 4」を対象にして、主に「Ops」に関連する主要な管理プラクティスについて見てきました。
次にサービスマネジメントを実現するためには、プラクティスに基づいた「サービスマネジメントシステム (SMS)」を構築し、「システム(仕組み)」として形作られることが必要であるとされています。
しかし実際問題として、これまでご紹介してきた管理プラクティスを理解し、みなさんがプロセスを設計してドキュメント化を行い、その内容をチーム全員に教育した上で、それを一定の品質を維持しながら継続的に実践していくことは、中々ハードルが高いと言わざるを得ません。。。
ここで思い出していただきたいのですが ITIL Version3 の「4つのP」や、ITIL 4 の「4つの側面モデル」においては、「プロダクト」や「技術」を上手く取り入れることが望ましいとされています。実際に ITIL に準拠し、各種プラクティスをすでにフレームワークとして組み込んでいる、数多くの優れたプロダクトが各社から提供されています。
つまり過度に「人(People)」や「プロセス(Processes)」に依存し過ぎることなく、ワークフロー機能を組み込んだ「プロダクト」や「技術」を活用した「サービスマネジメントシステム」を構築した上で、その「システム(仕組み)」のインターフェイスに導かれる形で「サービスマネジメント」を実践していくことが望ましい形ではないかと考えています。
次回の予告
このブログでは、実例を織り交ぜながらサブスク / DX 時代に求められる「Ops」のあり方について、複数回にわたって考えていきたいと思います。
今回は「ITIL 4」の第三弾として、主に「Ops」に関連する管理プラクティスのうち、インシデントや問題、継続的改善など、発生した課題の解決に必要となる、管理プラクティスについてご紹介しました。
次回は「サービスマネジメント」の実現に向けて、「サービスマネジメントシステム」を構築する上で必要となる、「サービスカタログ」を作成する方法についてご紹介します。
仲間を募集しています！
prismatix事業部では、お客様により良いサービスを提供し続けるために、一緒にお仕事をしていただける仲間を募集しています。
クラウドインフラエンジニアを募集しています！
現在、自社サービス 「prismatix」の事業拡大に伴い、インフラ運用・改善をご担当いただく以下２ポジションについて募集しています（ 2022/12 現在）。
それ以外の現在募集中のポジションについては下記のページからご確認ください。
もし気になるポジションがありましたらお気軽にお問い合わせください。
